Method for optically decoding a debit or credit card

ABSTRACT

A method for collecting and transmitting information desired for a commercial transaction from a debit or credit card uses a processor configured with optical character recognition (OCR) capability. At least one optical image of the debit or credit card is collected by the processor. The edges of the card are algorithmically defined from the collected image. Predefined offsets are applied to the algorithmically defined edges of the debit or credit card to algorithmically locate an area in the collected image having the desired transactional data. The transactional data within the located area is encoded and transmitted for further processing of the commercial transaction.

PRIORITY CLAIM

The present application claims priority to U.S. Provisional ApplicationSer. No. 61/596,385, filed Feb. 8, 2012.

FIELD OF THE DESCRIBED METHODS

The present subject matter relates to methods and systems for performingall logistical functionality (e.g., activation, sales, validation, etc.)of lottery and contest type tickets (e.g., instant lottery tickets,on-line lottery tickets, promotional materials, etc.) using existinginfrastructures without the need for additional lottery or game specifichardware installed at a retailer's location. Additionally, the use ofthe aforementioned infrastructures also enables street vendors toreadily: activate, sell, and validate lottery tickets, and to payapplicable prizes of lottery games. The proposed methodologies andsystems enable the sale/processing of lottery and contest tickets, aswell as interchange of other data (e.g., check clearing, authentication,etc.) between the retailer to a central processing hub without the addedexpense and inconvenience of installing custom hardware. Finally, amethod is disclosed to use off-the-shelf hardware to optically scandebit or credit cards in a secure fashion.

BACKGROUND AND SUMMARY OF THE INVENTION

Lottery games have become a time-honored method of raising revenue forstate and federal governments the world over. Traditional scratch-offand on-line games have evolved over decades, supplying increasingrevenue year after year. However, after decades of growth, the salescurves associated with traditional games seem to be flattening out withthe existing retailer base appearing to plateau. Consequently, bothlotteries and their service providers are presently searching for newsales venues.

One of the most promising genera of new lottery retailers are “big box”retailers (e.g., Walmart, Target, etc.) and drug store retailers (e.g.,Rite Aid, CVS, etc.). However, attempts by lotteries and their serviceproviders to recruit these new retailers have not succeeded. The mainreasons for the lack of success is that lottery products are too laborintensive and require special equipment. Additionally, aside from theadded cost of the special equipment, its placement may require big boxand drug store retailers to have a separate lottery sales/redemptionlocation possibly requiring extra staff. Additionally, in some venues itis desirable to use street vendors to sell lottery tickets that have notbeen able to use conventional lottery equipment and systems to providethe needed security for specialized lottery products.

To date, there have been numerous attempts to resolve this barrier tosales in big box and drug stores with special in-lane hardware (e.g.,Herndon et. al. US2009/0163263, etc.) as well as special monitorinterfaces to existing Point Of Sale (POS) systems (e.g., Behm et. al.U.S. Pat. No. 6,899,621), however all of these systems have required theaddition of special scanning or dispensing hardware that consequentlyincur significant costs.

Recently, the popularity of prepaid gift and debit cards (referred togenerically herein as “gift debit cards”) sold at big box and drug storeretailers has resulted in the implementation of barcode readingactivation systems tightly integrated with the stores' POS (Point OfSale) systems. Indeed, the $20 billion projected sales of open loop giftdebit cards for 201 have resulted in the vast majority of big box anddrug stores integrating gift/debit card activation systems into theirPOS systems. This mass adoption of gift debit card activation systemsallows for other products with barcodes and data conforming to the samespecifications as the gift card items to be activated, tracked, orvalidated without the need to add any additional hardware at theretailer location. Additionally, since gift/debit card activationsystems are already integrated into the stores' POS systems, there is noneed to have a separate location or additional staff to handle anyadditional products piggybacking on the gift debit card activationsystem.

This preponderance of existing gift debit card activation systems at bigbox and drug store POS systems creates the perfect foundation forlottery and contest systems to utilize the existing card activationnetwork to pass lottery/contest data between the retailer POS and acentral site database. By complying with the format of the gift cardactivation system, blobs of lottery or contest data can be interchangedbetween the retailer's POS and a central hub allowing transactions(e.g., instant sales, instant validation, instant inventory, quick pickbets, Power Ball validations, etc.) to be conducted without any customhardware.

Of course, the above data blob exchange utilizing the existing gift cardsystem can be applied to transactions other than lotteries and contests.In such an embodiment, the non-gift-card transactional data would alsobe encapsulated into a gift card activation network interchange. Forexample, driver's license data can be encapsulated into a gift cardactivation barcode format enabling it to be scanned and compared againsta central database for authentication beyond a visual inspection of thelicense.

The concept of no or little customized hardware at the POS location canbe extended to a portable retailer or street vendor. In this embodiment,off-the-shelf smart telephones can be incorporated as barcode scannersand the retailer interface, with a portable printer providing thenecessary receipts and tickets. Indeed, with portable retailers orstreet vendors, the gift card network can be used to activatetraditional plastic open loop debit cards that can be loaded withlottery or contest prize winnings at the time a winning ticket ispresented to the street vendor. With this embodiment, the street vendoror portable retailer is no longer required to carry sufficient cash topay winners, thereby helping to protect the vendor from theft andviolent crime. Additionally, the smart telephone camera can be used toprocess an image of a debit or credit card with built-in OpticalCharacter Recognition (OCR) allowing the street vendor to perform saleswithout accepting cash.

Therefore, it is desirable to develop methodologies for performinglottery and other transactions at the retailer POS requiring no specialhardware.

Described herein are a number of mechanisms illustrating the practicaladvantages of as well as the details of reliably utilizing existinginterchanges to eliminate the logistical need for any custom hardware ata retailer POS. The disclosed mechanisms thereby offering substantialsavings (in eliminating hardware costs and maintenance) while at thesame time reducing the clutter on retailer's counters as well assimplifying the retailer interface.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart of a representative example of the existingcredit/debit card interchange network used for debit or credit cardprocessing;

FIG. 2 is a back plan view of a first representative example of an openloop gift card package;

FIG. 3 is a flow chart of the representative example of the existingcredit/debit card interchange network of FIG. 1 when it is utilized foropen loop gift card activation;

FIG. 4 is a front plan view of a first representative example of a debitor credit card account number taxonomy;

FIG. 5 is a block diagram of a first representative example of a datapacket with a lottery BIN (Bank Identification Number) and associatedinstant ticket inventory data blob compatible with the interchangenetwork of FIG. 6;

FIG. 6 is a flow chart of the representative example of the existingcredit/debit card interchange network of FIG. 1 when it is utilized forinstant (scratch-off) lottery ticket sales;

FIG. 7 is a front plan view of a first representative example of aninstant ticket inventory reporting card compatible with the interchangenetwork of FIG. 6;

FIG. 8 is a block diagram of a first representative example of a datapacket with a lottery BIN and associated instant ticket inventoryrequest blob compatible with the interchange network of FIG. 6;

FIG. 9 is a block diagram of a first representative example of a datapacket with a lottery BIN and associated instant ticket validationrequest blob compatible with the interchange network of FIG. 6;

FIG. 10 is a front plan view of a first representative example of aninstant ticket validation initiation card compatible with theinterchange network of FIG. 6;

FIG. 11 is a flow chart of the representative example of the existingcredit/debit card interchange network of FIG. 1 when it is utilized foron-line lottery ticket sales;

FIG. 12 is a front plan view of a first representative example of aquick-pick card compatible with the interchange network of FIG. 11;

FIG. 13 is a block diagram of a first representative example of a datapacket with a lottery BIN and associated instant ticket inventoryrequest blob compatible with the interchange network of FIG. 11;

FIG. 14 is a front plan view of a first representative example of anon-line game ticket compatible with the interchange network of FIG. 11;

FIG. 15 is a block diagram of a first representative example of a datapacket with a lottery BIN and associated on-line ticket validationrequest blob compatible with the interchange network of FIG. 11;

FIG. 16 is a front plan view of a first representative example of alottery street vendor with off-the-shelf hardware;

FIG. 17 is a front plan view of a first representative example of debitor credit card suitable for Optical Character Recognition (OCR);

FIG. 18 is a front plan view of a first representative example of adelta memory map of the debit or credit card image of FIG. 17;

FIG. 19 is a flow chart of the representative example of the existingcredit/debit card interchange network of FIG. 1 when it is utilized forportable lottery functionality;

FIG. 20 is a front plan view of a first representative example of a realtime printed passive ticket;

FIG. 21 is a front plan view of a first representative example of apreprinted passive ticket;

FIG. 22 is a flow chart of the representative example of the existingcredit/debit card interchange network of FIG. 19 utilized for with thesame acquiring and issuing processor;

FIG. 23 is a flow chart of the representative example of portablelottery system linked directly to a central site with an additionalchannel to existing credit/debit card issuing and acquiring processor;

FIG. 24 is a front plan view of a first representative example of asmart telephone running a lottery application enabling the selection ofonline (e.g., Powerball, Pick 3, Pick 4, etc.) numbers; and,

FIG. 25 is a front plan view of the first representative example of asmart telephone running a lottery application of FIG. 22 displaying agift card activation compatible barcode to be scanned by the retailer'sPOS device to register an online bet over the gift card activationinterchange.

DETAILED DESCRIPTION

There are multiplicities of existing networks that can be utilized toexchange data without the logistical challenges of installing customhardware. FIG. 1 depicts a representative example of the existingcredit/debit interchange network that is presently utilized forpurchases as well as open loop (i.e., can be used anywhere theinterchange provider's card is accepted) gift/debit card activation. Fora normal transaction, the consumer 100 makes a purchase (eitherin-person or on the Internet) and the merchant 105 accepts his debit orcredit card data 106. The debit or credit card data 106 account numberand other data, along with the cost of sale, is transmitted to themerchant's 105 acquiring processor 110—i.e., the institution that hascontracted with the merchant to exclusively conduct his or her debit orcredit card transactions. The acquiring processor 110 then forwards thetransaction information to the interchange 120, garnering a fee for hisor her troubles. The credit or debit card interchange 120 is actuallycomprised of multiple operators (e.g., Visa, MasterCard, Discover,etc.), which the acquiring processor directs the transaction toaccording to the first digit of the debit or credit account number 106.After the transaction data has been passed to the appropriate operatoron the interchange 120 then, based on the Bank Identification Number(BIN) embedded in debit or credit account number 106, forwards thetransaction information to the Issuing processor 125 of the card andgarners a fee or levy of the transaction sale.

The issuing processor 125 of the debit or credit card account number 106then queries the cardholder's bank 130 to determine if sufficient fundsare available to cover the purchase. Assuming the funds are available,the issuing processor 125 then sends the approval notice back throughthe interchange 120 garnering a fee. This approval is then routed backthrough the acquiring processor 110 to the merchant 105 who delivers thegoods. The actual funds are then electronically transferred from thecardholder's bank 130 to the merchant's bank 115 as a separate processwith the consumer cardholder 100 ultimately receiving a statement thatthe transfer occurred.

This same interchange network of FIG. 1 is leveraged to enablegift/debit card activation at the time of sale. However, when typicallyactivating a gift debit card its security package 150 (FIG. 2) UPC(Universal Product Code) 151 and proxy activation 152 barcodes arescanned to initiate the activation process.

In some merchant system's the scanning of the UPC barcode 151 assignedto a gift card package 150 (FIG. 2) informs the system that the nextbarcode scanned will be a proxy activation barcode 152 in a formatcompatible with the debit or credit card interchange. Therefore, in thisembodiment, the merchant system automatically scans the subsequent proxyactivation barcode 152 and sends the resulting scanned data through theinterchange for gift debit card activation. Alternatively, othermerchant systems do not employ this previously discussed UPC/proxybarcode state machine embodiment. Rather, in this new embodiment, themerchant system identifies unique characteristics of the gift-debit-cardproxy barcode 152 and automatically routes the subsequent data throughthe debit credit card interchange regardless of the nature of thebarcode previously scanned. With either gift-debit-card activationembodiment, once the POS equipment has scanned the gift debit card proxybarcode 152 the collected data is routed through the interchange.

As illustrated in FIG. 3, in any gift debit card activation process theconsumer 100 takes the gift debit card package 150′ to the merchant 105who first scans the package 105 (FIG. 2) UPC barcode 151 and then theproxy activation barcode 152. As previously discussed, the existingmerchant POS equipment automatically routs the scanned data from thesubsequent proxy activation barcode 152 through the acquiring processor110 (FIG. 3) and through the interchange 120 to the issuing processor125. The issuing processor 125 receives the specially formattedgift-debit-card activation request, checks to determine if the number isauthentic, and assuming it is authentic ensures that the issuing bank130 reserves sufficient funds in the gift debit card account to coverthe gift card value. (Typically, the FIG. 3 gift-debit-card sellingmerchant's 105 bank account 115 is swept for the funds to financepurchases within twenty-four hours after the sale of the gift debitcard.) At this point, the issuing processor returns an acknowledgementto the merchant POS 105 via the interchange 120 and acquiring processor110 that commands the merchant POS 105 to print an activation receiptfor the consumer 100. As before, the acquiring processor 110 andinterchange 120 garner fees for passing the data.

In all of the above debit or credit card transaction or gift cardactivation transactions, the data is transferred from the acquiringprocessor 110 (FIG. 1 and FIG. 3) through the interchange 120 to theissuing processor 125 by the numbering scheme of the debit or creditcard 170 account number 171 as illustrated in FIG. 4. As shown in FIG.4, the first four to six digits 172 constitute the Bank IdentificationNumber (BIN) identifying the institutions (i.e., issuing processor andinterchange operator) issuing/routing the card and associated data.Although it is called a Bank Identification Number, BINs can be used byother institutions, such as American Express or Western Union.Regardless of the institution, the BIN is always used by the acquiringprocessor 110 (FIG. 1 and FIG. 3), the interchange 120, and the issuingprocessor 125 to correctly route the transaction request. Multiple BINscan be assigned to the same issuing processor 125, allowing for theissuing processor 125 to support different functionality—e.g., differentbanking institutions 130, gift debit card activation, etc. Of course,the same BIN numbering scheme is also employed on gift debit card proxynumbers 152 (FIG. 2).

Thus, for a normal debit or credit card transaction or gift cardactivation, there is a minimum of four to seven entities involved eachgarnering fees. As will now be shown, this same interchange network canbe used to integrate seamlessly into a lottery or contest system withoutthe need of additional specialized hardware and its associatedlogistical costs. The main component being assigning a unique BIN to alottery or contest system.

In one embodiment, assigning and printing a unique lottery BIN in thebarcode on instant lottery tickets supplies all of the informationnecessary to route the instant ticket inventory control data through thedebit or credit interchange. This data routing will automatically occurbecause the debit or credit interchange only uses the BIN to direct datathrough the interchange, with the remaining data in a debit or creditcard number not processed by the interchange itself. (Strictly speaking,the above statement is not entirely correct; there can be a check digitembedded in the remainder of the debit or credit card data that ensuresthe integrity of the data being transmitted, however tis same checkdigit format can be calculated and embedded in other non-credit/debitcard data.) Any data transmitted with the BIN is simply carried as a‘data blob’ 182 (FIG. 5) that only has significance to the issuingprocessor 125 (FIG. 1 and FIG. 3). By assigning a unique lottery BIN 181(FIG. 5) and concatenating instant ticket inventory control data as theassociated data blob (182) the resulting data packet 180 will seamlesslypass through the interchange in a manner similar to a debit or creditcard transaction. When the issuing processor 125 (FIG. 1 and FIG. 3)receives the concatenated packet 180 (FIG. 5), the issuing processorservers would know from the special lottery BIN 181 that the encloseddata blob 182 contained lottery information and to subject the packet tospecial processing either at the issuing processor 125 (FIG. 1 and FIG.3) or another location.

Of course, as is obvious to anyone skilled in the art, this sametechnique of leveraging the interchange network and assigning uniqueBINs can be used for other types of data transfer (e.g., consumerauthentication, check cashing, etc.) requiring information to beexchanged between the merchant's POS system and a central dataprocessing hub.

Applying the interchange network of FIG. 1 and FIG. 3 to enable instant(scratch-off) lottery ticket sales then is a matter of configuring theinstant ticket barcode to a format resembling a proxy number barcode 180(FIG. 5) and adding an interface from the issuing processor 125 to alottery's central site server 160 (FIG. 6). In this system the instantlottery ticket consumer 100′ would purchase an instant lottery ticket155 from a merchant 105. The merchant 105 scans the instant lotteryticket's 155 UPC and/or proxy number compatible barcodes toautomatically trigger the merchant's POS equipment 105 to route thelottery ticket's 155 proxy number compatible barcode data 180 (FIG. 5)to the acquiring processor 110 (FIG. 6), through the interchange 120, tothe specified issuing processor 125, and then ultimately to thelottery's central site 160.

In this embodiment, processing the sale of instant lottery tickets 155is accomplished by the lottery prearranging to have a special datainterface 161 between the lottery's central site 160 and the issuingprocessor's 125 servers. The exact nature of this interface 161 can varyso long as sufficient techniques are employed for the link to remainsecure to data manipulation or monitoring: However, in the preferredembodiment a Virtual Private Network (VPN) would be employed to ensurethat the interface 161 was authenticated and encrypted, with its uniqueInternet Protocol (IP) addresses secured from monitoring. Regardless ofthe low level details of the interface 161, the data exchanged for aninstant lottery ticket sale (i.e., embedded in the data blob 182 (FIG.5)) would be the instant ticket proxy barcode data and an identifyingcode of the retailer making the sale.

Returning to FIG. 6, once the issuing processor has forwarded theinstant lottery ticket sale information and the retailer identificationcode to the lottery's central site 160, the lottery's servers will logthe sale, thereby maintaining a record on the lottery's database. Ifdesired, the same lottery central site 160 can transmit a print receiptcommand back through the interchange network 120 and the acquiringprocessor 110 to the merchant's POS 105 printer thereby completing thesale. Since piggybacking on the debit or credit interchange logs everyinstant ticket sale; inventory control and the problem of maintaining acentralized inventory control for instant ticket sales can be resolvedby supplying the merchant with a special barcoded inventory controlreport card 175 (FIG. 7). By scanning the proxy compatible barcode 177on the inventory control report card 175 the merchant would be able touse the debit and credit interchange to send a request for an instantticket inventory report through the acquiring processor 110 (FIG. 6),interchange 120, and issuing processor 125 to the lottery's central site160. When the request is received at the lottery's central site 160, itsservers will generate the requested inventory report and send a seriesof print commands back through the same interchange path to cause themerchant's POS printer to print a hardcopy of the report at themerchant's location 105. Of course, for this system to work, eachmerchant would have to be assigned an unique inventory report card 175(FIG. 7) with the merchant's identity encoded on the card both as humanreadable 176 as well as embedded in the proxy barcode 177. As before theinventory request proxy barcode 177 would be configured with the lotteryBIN 186 (FIG. 8) concatenated to the merchant's instant ticket inventoryrequest as the associated data blob (187) with the resulting packet 185passed through the interchange in a manner similar to a gift cardactivation transaction. However, in this embodiment the store inventoryrequest would be a flag to alert the lottery central site 160 (FIG. 6)that the transaction is an inventory request and possibly identifyingdata unique to the merchant issuing the request.

Alternatively, the merchant could be provided with a special applicationon a computer or mobile device that query the lottery central site 160via communications channels (e.g., the Internet) alternative to theinterchange. The significant point being that inventory reporting andcontrol are enabled by the lottery's central site 160 logging everyinstant ticket sale.

Inventory control of instant lottery tickets has been a particularlyvexing problem in the past, with the primary solution to date being toinstall one form or another of vending devices at the merchant'sestablishment, thereby keeping the instant ticket inventory under lockand key with an automated device tabulating how many tickets were sold.The disadvantages of this approach being the high cost of vendinghardware as well as the logistical problems associated with installingand maintaining the vending hardware, in addition to the physical spacethe vending hardware consumes. Alternatively, a barcode readerinterfaced to a lottery terminal already installed at the retailer hasalso been attempted for instant ticket inventory control. However, thisalternative had the disadvantages of requiring the retailer to interfacewith two devices (i.e., POS equipment and the lottery terminal) as wellas the extra cost associated with requiring custom hardware to beinstalled at the retailer's place of business.

Aside from eliminating the need for special vending hardware, utilizingthe debit or credit interchange allows the merchant 105 (FIG. 6) toaudit his or her instant ticket inventory at any time, significantlyreducing the motivation for theft since missing instant ticket inventorycould be detected more easily. Moreover, the utilizing of the merchant'sPOS 105 register to log each ticket sold enables each instant ticket tobe activated on an individual basis. The term ‘activation’ in thiscontext meaning that the lottery central site only allows activatedtickets to be validated resulting in payment of prizes.

The last point is significant. Traditionally instant tickets aretypically shipped in packs of twenty to one hundred with the pack itselfbeing the unit of activation. This gross quantization of activation hascaused numerous problems throughout the history of the lottery industry.For example, individual instant tickets stolen from an activated packcan be validated on a lottery system so long as the pack is not reportedstolen. Conversely, when a partial pack is reported stolen the problemof estimating, which tickets in the stolen pack were legitimately soldand which were stolen remains. Additionally, pack rather than ticketactivation forces lotteries to rely on winning ticket validations toestimate sales to consumers—i.e., a crude metric at best with typicallyonly 1 out of 5 tickets winning. Furthermore, the pack activation modelcan allow a significant amount of free retailer financial float, sincethe retailer can sometimes begin selling from a pack of instant ticketsand not have to reconcile until 90 days after activation.

All of these pack activation problems are solved with the lotterycentral site 160 (FIG. 6) being cognizant of every instant ticket sale.However, with specially installed hardware at the merchant'sestablishment logging each ticket sale for activation has proven not tobe been practical or economical. One of the main reasons being thatcustom lottery hardware is by necessity placed in a different locationthan the merchant's cash register, making it inconvenient for themerchant to execute the sale in one location and scan the instantticket's inventory control barcode in a different location. While it ispossible (at some expense) to install a separate barcode scanner nearthe merchant's cash register with an interface to the lottery terminal,the clerk would still be obliged to perform two operations with twodifferent user interfaces—i.e., problematic at best. Even if a customhardware device is installed on the merchant's cash register to monitorscanned UPC barcode data for lottery assigned UPC data (e.g., Behm et.al. U.S. Pat. No. 6,899,621) the instant ticket inventory/activationproblem persists, because the UPC data does not contain ticket inventorycontrol information needed for ticket level activation. In other words,all instant lottery tickets of the same game would share the same UPCdata, making it extremely difficult to distinguish which ticket serialnumbers were sold. However, by piggybacking on the debit or creditinterchange with lottery instant ticket sales, the logging/activationmechanism leverages the same user interface that the merchant useseveryday as well as the same physical procedure used for gift debit cardactivation.

The same piggyback via BIN mechanism that enables instant ticket salescan also be utilized for validation of winning instant tickets. In thiscontext, the term validation means authenticating a perceived winningticket by interfacing with the lottery central site. Not surprisingly,the piggybacking on the interchange configuration for instant ticketvalidation is essentially the same as instant ticket sales (FIG. 6).

In the preferred embodiment, processing an instant ticket validationbegins with the lottery instant ticket consumer 100′ presenting aperceived winning instant ticket 155 to the merchant 105 for prizepayment. The merchant scans the barcode that was hidden under theunplayed ticket's Scratch-Off-Coating (SOC). As previously discussed,the merchant may have to first scan the instant ticket's UPC barcode toplace his or her POS equipment into a special state to process the proxybarcode. This barcode configured to be compatible with the proxy datanormally passed over the debit or credit interchange 120 with thelottery BIN 191 (FIG. 9) concatenated to a data blob (192) containingthe ticket's validation data forming the whole proxy data 190. In thiscontext, the term ‘validation data’ refers to data not available untilafter the instant ticket is played (i.e., SOC removed) that is used bythe lottery central site 160 (FIG. 6) to determine if the ticket is awinner or not.

In another embodiment, the lottery instant ticket consumer 100′ presentsa perceived winning instant ticket 155 to the merchant 105 for prizepayment. However, in this embodiment, the validation barcode previouslyunder the SOC is unreadable or for other reasons unavailable. Thus, inthis embodiment the merchant scans the barcode 197 (FIG. 10) on aspecial validation card 195 that places the merchant's POS equipment ina special state to validate instant tickets. Since the specialvalidation card 195 initiates the validation process, a UPC format maybe required on the card's 195 barcode 197 to be compatible with some POSequipment. In this case, special UPC data would be reserved for instantticket validation purposes that would not automatically count as a saleon the POS equipment's database. After the validation card's 195 barcode197 is scanned and the merchant's POS equipment is in a state to processinstant ticket validations, the merchant would scan the instant ticketinventory control barcode that was used to register the sale on thelottery's central site. At this stage, the validation transaction canproceed. For extra security, the merchant's POS equipment may prompt themerchant to key in numerical data that would be hidden under the SOC ofan unsold ticket but exposed after the SOC is removed.

Returning to FIG. 6, with either embodiment once the validation processwas initiated by the merchant 105, the validation data (eithervalidation barcode data, inventory barcode data, or inventory barcodeplus added data) will be transmitted through the acquiring merchant 110and the interchange 120 to the issuing processor 125. At this point theissuing processor 125 would have detected the lottery BIN in thetransaction and forwarded the validation to the lottery central site 160via the dedicated communications channel 161.

The lottery central site 160 will then: extract the validation data fromthe transaction's data blob 192 (FIG. 9), determine from flags withinthe data blob 192 that the associated data is an instant ticketvalidation and processes the validation. Alternatively, an unique‘lottery validation BIN’ could be employed to still direct thetransaction to the lottery central site 160 (FIG. 5), but eliminate theneed to embed a flag in the data blob 192 (FIG. 9) informing the lotterycentral site 160 (FIG. 6) that the associated data is a lotteryvalidation transaction. In both cases, the lottery central site 160 willdetermining if in fact the validation request is associated with awinning ticket and route the appropriate response back through the sameinterchange path to the merchant 105, causing either an authorization topay or a message not to pay a prize to be printed on the merchant'sprinter 105.

Aside from instant ticket processing, the same piggybacking via BINmechanism over the interchange that enables instant ticket sales canalso be utilized for on-line (e.g., Pick 3, Pick 4, Powerball, MegaMillions, etc.) sales and validation. As illustrated in FIG. 11, thedebit or credit card interchange usage for on-line lottery transactionsis virtually identical to instant ticket transactions (FIG. 6) with theonly difference being the actions of the consumer 100″ (FIG. 11) and themerchant 105.

For quick-pick (i.e., numbers automatically selected for the consumer)purchases of on-line tickets, the consumer would either take a plastichanging card 200 (FIG. 12) with a quick-pick coded interchangecompatible barcode 201 to the merchant or simply ask the merchant for aquick-pick for a given on-line game (e.g., Pick 3, Pick 4, Powerball,Mega Millions, etc.) The merchant would either take the hanging card orpull one from behind the counter (or from a pocket in the case of astreet vendor) and scan the UPC barcode for the quick-pick sale (202)followed by the interchange compatible barcode 201 to trigger aquick-pick request. In either case, the interchange compatible barcode201 will be configured to be compatible with the proxy data normallypassed over the debit or credit interchange 120 with the lottery BIN 206(FIG. 13) concatenated to a data blob (207) containing the quick-pickrequest data forming the whole proxy data 205.

As before, the pending quick-pick transaction is forwarded to theacquiring processor 110 (FIG. 11), routed through the interchange 120,to the issuing processor 125. The issuing processor would then detecteither a lottery BIN or a special ‘lottery quick-pick BIN’ and route thepending transaction through the designated channel 161 to the lottery'scentral site 160 or complementary gaming system. The lottery's centralsite or complementary gaming system would then decode the quick-pickrequest, use a random number generator to generate a pseudorandomquick-pick, log the quick-pick transaction with a generated serialnumber on its database, and transmit a print command documenting thequick-pick and the assigned serial number to be printed on themerchant's printer at his or her location 105 and recorded at thecentral site at a later time if a complementary gaming system is used.

It should be noted, that until recently the printing of quick-pickticket printing process would not have been possible via the piggybackinterchange BIN mechanism. This is because on-line tickets aretraditionally printed on ticket stock with serial numbering preprintedon the back along with other security features (e.g., ultravioletvisible ink). The preprinted serial numbering and other featuresproviding added security in determining the authenticity of an apparenthigh-tier winning ticket. Therefore, the need for special preprintedsecurity paper would prohibit a merchant from printing quick-picktickets using his or her normal cash register or other printer—i.e., thelogistical challenges would prohibit merchants from loading speciallottery paper into their cash register. Alternatively, the merchantcould be supplied with a special lottery printer that uses the specialsecurity paper, but the addition of a lottery printer would necessitatecustom lottery interfaces for the merchant's POS equipment, increasingthe costs and re-introducing custom lottery hardware at the POS.

Fortunately, recently two Ticket Message Authentication Code (T-Mac)patents have issued (i.e., Irwin U.S. Pat. No. 7,788,482 and U.S. Pat.No. 8,037,307) which eliminates the need for special security paper foron-line tickets by employing cryptographic techniques that add a MessageAuthentication Code (Mac) to the ticket's serial number that make itvirtually impossible to copy or forge the ticket. However, the T-Macpatents reference certain cryptographic functions being performed byfield lottery terminals. In the context of the piggyback interchange BINmechanism, the lottery terminal would be the merchant's POS equipment105 (FIG. 11). In a preferred embodiment, the T-Mac applicable softwareis loaded into the merchant's POS equipment. This embodiment has theadvantage of a wide terminal distribution and no additional hardware atthe retailer's location. However, while loading the necessarycryptographic software onto the merchant's POS equipment 105 iscertainly feasible, it does offer certain logistical challengesassociated with loading specific purpose software on POS equipment.Another embodiment would be to add lottery specific hardware to processT-Macs to each POS register, however this embodiment has thedisadvantage of the added hardware costs as well as the logisticalchallenges (e.g., installation, POS driver software, etc.) associatedwith connecting specific hardware to retailer's POS equipment. In yetanother embodiment, the lottery T-Mac subsystem could leverage. In yetanother embodiment, the lottery T-Mac subsystem could leverage themultiple parties inherent in the piggyback interchange BIN system, tosupply the required remote cryptography functionality via another entitythan the lottery central site. While not as inherently robust, thisembodiment would have the advantage of not needing any softwaremodifications to the merchant's POS equipment, thereby eliminating theassociated logistical challenges. While in theory, any party couldimplement a T-Mac system, in a preferred embodiment the issuingprocessor 125 would provide a separate server that would assign separatecryptographic keys to each participating merchant 105. Thus, when aquick-pick transaction was conducted, the issuing processor's 125 T-Macserver would intercept all quick-pick print commands sent from thelottery central site 160 that were transmitted through the lotterytransaction channel 161. The issuing processor 125 T-Mac server wouldthen create the appropriate Message Authentication Code (Mac) for theassociated quick-pick serial number, appending it to the print commandsent to the merchant 105 thereby completing the sale. Thus, in thisembodiment, the T-Mac security which is partially derived fromseparation of cryptographic keys from the lottery central site 160 ismaintained by locating a T-Mac server at the issuing processor 125. Ofcourse, as is obvious to anyone skilled in the art, other cryptographicembodiments are possible and may be preferable depending on thelottery's business relationships with the various entities on or off theinterchange.

Validations of on-line game tickets (e.g., Pick 3, Pick 4, Powerball,Mega Millions, etc.) are conducted similar to instant ticket validation.In the preferred embodiment, processing an on-line game ticketvalidation begins with the lottery on-line ticket consumer 100′presenting a perceived winning on-line ticket 210 (FIG. 14) to themerchant 105 (FIG. 11) for prize payment. Assuming the POS equipmentrequires an UPC barcode scan, the merchant first scans the on-lineticket's 210 (FIG. 14) UPC formatted barcode 211 to place the POSequipment in a state to receive gift debit card activation data. Itshould be noted; special UPC data would be reserved for on-line ticketvalidation purposes that would not automatically count as a sale on thePOS equipment's database. Immediately after, the merchant scans theon-line ticket's 210 UPC formatted barcode 211 and then the secondinterchange compatible barcode 212. Alternatively, the merchant's POSequipment could be configured to recognize interchange compatiblebarcode formats 212 without being placed in a special state. If this isthe case, the on-line ticket may omit the UPC formatted barcode 211.

In either case, the interchange compatible barcode 212 will beconfigured to be compatible with the proxy data packet 215 (FIG. 15)normally passed over the debit or credit interchange with the lotteryBIN 216 concatenated to a data blob (217) containing the on-line ticketvalidation request. Optionally, the proxy data packet 215 could alsocontain a T-Mac in addition to the standard lottery on-line ticketserial number.

Returning to the pending on-line ticket validation, the merchant's POSequipment 105 (FIG. 11) would then forward the interchange compatiblepacket 205 (FIG. 13) (including the embedded on-line ticket data blob207) to the acquiring processor 110 (FIG. 11), that would then use theBIN header 206 (FIG. 13) information to route the packet through theinterchange 120 (FIG. 11) to the acquiring processor 125. The acquiringprocessor's 125 servers would then detect the lottery BIN and forwardthe received data packet through the interchange 120 to the issuingprocessor 125 which would then forward the data packet through thelottery transaction channel 161 to the lottery central site 160. Thelottery central site would then extract the on-line ticket validationrequest, comparing the received serial number to a drawing database todetermine if the scanned ticket's serial number is a winner or not andif it was previously cashed. Optionally, if a T-Mac were present withthe scanned ticket's serial number, the lottery central site 160 wouldalso perform a cryptographic function on the T-Mac to determine if theresulting clear text is compatible with the ticket's serial number. Thelottery central site would then send a print statement back through theinterchange 120 to the merchant's POS equipment 105 where awinning/losing receipt would be printed.

Of course, the entire debit or credit interchange only exists because itgarners fees per transaction. With piggybacking on the debit or creditinterchange for lottery transactions, this paradigm need not change.When the high costs of manufacturing, installing, maintaining, andcommunicating with custom lottery field hardware is taken into accountthe economics of paying a small fee per lottery transaction withvirtually no upfront costs becomes attractive. Essentially the lotteryeconomic model changes from a system with significant upfront costs aswell as continuing communications charges, to a leased services modelthat only pays per transaction with the benefit of virtually no upfrontor continuing communications costs.

Indeed, when a lottery service provider wins a bid for providing,installing, and maintaining lottery equipment, the lottery serviceprovider must pay for the equipment and network at the time of contractaward. The lottery service provider hoping to regain the massive capitaloutlay as well as associated finance charges throughout the course ofthe contract—i.e., typically lottery contracts in the U.S. providelittle or no payments at contract award. This is why publicly tradedlottery service providers typically report lower quarterly earningsimmediately after they win large new lottery contracts. In other words,the capital outlays required to finance a lottery contract startupeffort tend to consume any available revenue in the same fiscal quarter.

Aside from virtually eliminating lottery startup costs, recent UnitedStates federal legislation (e.g., Durbin amendment) limiting what thedebit or credit card interchange can charge per transaction have forcedinterchange providers to look for new sources of revenue. This is turn,makes piggybacking on the debit or credit interchange for lotterytransactions more attractive to not only the lottery service providersbut the interchange providers as well. Thereby creating a synergisticopportunity for all parties involved.

Of course, as is obvious to one skilled in the art, other establishedretail network systems (e.g., coupon validation) can be employed toprovide the same sans custom hardware functionality as the debit orcredit card interchange previously described and indeed, in somecircumstances may be preferable.

In addition to brick and mortar merchant locations, the notion of sanscustom hardware lottery or contest operations can be expanded to streetvendors. While unusual in the United States, street vendors are a commonsight in developing countries creating sales without the need for anestablished lottery infrastructure using brick and mortar locations.Traditionally, these street vendors would roam with a limited inventoryof instant tickets literally conducting street sales and paying smallprizes on the spot. The typical lack of connectivity to a lotterycentral site forces the street vendor to reconcile at the end of theday, matching unsold inventory and claimed tickets with the amount ofcash reserves at the end of the day. This lack of connectivity and theneed to carry potentially large amounts of cash have created securityproblems for the street vendor.

However, smart phone technology has recently become sophisticated enoughto permit programming cell phones (to do computations, performfunctions, and store data) previously reserved for laptop or desktopcomputers. The latest generation of these smart phones is equipped withhigher resolution cameras that can function to record information thatcan also be transmitted over a cellular network.

Technology has also evolved in the automobile rental industry thatpermits hand held thermal printers with barcode scanners and keyboardsto communicate with servers over short distances to exchangeinformation, complete transactions and print receipts for customersremote from traditional clerks stationed at immobile terminals.

Given these advancements and their equipment miniaturization, there arenow alternatives that can allow lottery transactions that have beenrestricted to stationary locations to become fully portable andadaptable for street vendor use. The synergistic coupling of these newergeneric hardware technologies with cellular networks and associatedpayment mechanisms allows for street vendor based lottery systems tooperate without the need and associated expense of custom hardware.Additionally, by using debit cards both for procurement and prizepayments with off-the-shelf equipment and networks reduces both thepotential for street vendor fraud as well as reduces the risksassociated with robbery since the vendors will no longer need to carrylarge amounts of cash on their persons.

In one embodiment, the street vendor 220 (FIG. 16) is equipped with atablet computer/communications device (e.g., Apple iPad) 221 as well asa portable battery powered printer (e.g., HP Officejet H470) 222,instant lottery tickets 223, and debit cards with no cash value loaded(not shown in FIG. 16). Thus in this embodiment, no special lotteryequipment is carried by the street vendor. However, it should be noted,that even though this embodiment utilizes off-the-shelf equipment andnetworks there is still the need for lottery customized software (in theform of an application) to be resident on the computing/communicationsdevice 221 (e.g., iPad). Additionally, there may be a requirement foraccessories to accommodate connecting the off-the-shelfcomputing/communications device 221 to a mobile communications networkstandard or to other support hardware. For example, the portable batterypowered printer 222 sited in the above text is a HP Officejet modelH470, which would require a wireless dongle to interface with the sitedtablet computer/communications device iPad 221 over an 801.11 (WiFi)wireless link along with loading a free HP ePrint app on the tabletcomputer/communications device 221.

In this embodiment, the street vendor 220 would be able to sell bothinstant and on-line (e.g., Pick 3, Pick 4, etc.) lottery tickets as wellas validate and redeem both. Additionally, like the debit or credit cardinterchange piggyback embodiment with brick and mortar merchants, thestreet vendor 220 would also be able to activate instant lottery tickets223 individually at the time of sale. The advantages being bothautomatic inventory accounting as well as reduced chances of theft sincethe un-activated instant tickets 223 would not validate or redeem on thelottery system.

An instant ticket sale would be conducted by the street vendor receivingpayment for an instant ticket which he or she would log into theirportable tablet computer/communications device 221 either by touchscreennumerical entry or, preferably, by scanning a debit card for payment.The touchscreen numerical entry being primarily envisioned for cashsales and therefore having the disadvantage of possibly burdening thestreet vendor 220 with large sums of cash with the inherent securityrisks. In a preferred embodiment, a debit (or possibly credit) card isaccepted for payment—i.e., depending on the laws in the lottery'sjurisdiction, it may not be legal to accept credit cards as a form ofpayment for the sale of lottery products. In this embodiment, the streetvendor 220 would scan or swipe the debit or credit card also scanningthe barcode of the instant ticket(s) being sold on the tabletcomputer/communications device 221. Swiping of the debit or credit card(i.e., acquiring the magnetic stripe or smart card data) could beaccomplished with a third party off-the-shelf portable reader (not shownin FIG. 16), however this embodiment has the disadvantage of encumberingthe street vendor 220 with another device to carry, as well as powersource and interface. In a preferred embodiment, the street vendor 220would instead use the built-in camera typically found on the portabletablet computer/communications device 221 to collect one or more imagesof the debit or credit card for Optical Character Recognition (OCR)processing of the embossed or printed card data.

With either embodiment, once the instant ticket and payment informationhas been collected by the street vendor's 220 portable tabletcomputer/communications device 221, the information is transmitted tothe lottery central site. The instant ticket is then activated on thelottery central site database and an acknowledgement is transmitted backto the street vendor's 220 portable tablet computer/communicationsdevice 221.

A similar methodology can be employed to minimize cash outlays when thestreet vendor 220 is paying out prizes. In this embodiment, the streetvendor 220 receives an apparent winning instant or on-line ticket fromthe consumer for payment. The street vendor 220 then scans the barcodeof the apparent winning ticket with the portable tabletcomputer/communications device 221 with the decoded ticket barcode datatransmitted to the lottery central site. The central site then checksits database to confirm that the ticket is in fact a winner and has notbeen previously paid. Assuming the ticket qualifies the central sitethen transmits to the street vendor 220 portable tabletcomputer/communications device 221 an authorization to pay data packet,which is physically printed on the street vendor's 220 portable printer222. Once the authorization to pay is received, the street vend& 220could pay the consumer with cash, but preferably the street vendor 220would produce a heretofore not activated debit card and scan the cardwith the portable tablet computer/communications device 221 camera. Thuscollecting one or more images of the debit for OCR processing of theembossed or printed card data for extraction of the card's accountnumber. When the account number is determined (by OCR or other means),the card account data is transmitted to an issuing processor along withthe authorized prize amount. The issuing processor then activates theassociated debit card account funded by the winning prize amount. Anacknowledgement is then transmitted back to the street vendor 220portable tablet computer/communications device 221, which is physicallyprinted on the street vendor's 220 portable printer 222. Of course, ifthe consumer already has a debit card, the above prize payment processcould also be utilized to deposit the winnings directly into theconsumer's card account.

As is obvious to anyone skilled in the art, the above debit card paymentmeans could be implemented by swiping the card or manual entry and maybe preferable under some circumstances. However, the OCR card-scanningembodiment is generally preferred to reduce the amount of hardwarecarried by the street vendor 220 as well as possibly providing a highersecurity means of debit or credit card scanning.

A typical credit or debit card 230 is illustrated in FIG. 17. Since thetypical credit or debit card 230 is made to specific dimensions,—i.e.,ISO/IEC 7810:2003 specifying the width 231 (FIG. 17) as 85.60 mm (3.370inches) and the height 232 as 53.98 mm (2.125 inches)—the OCR decodersoftware resident in the portable tablet computer/communications device221 (FIG. 16) has the advantage of being able to automatically calibratefor the angle the debit or credit card 230 (FIG. 17) is held relative tothe camera. Thus, by first programming the OCR software to detect theedges of the credit or debit card 230 then comparing the differencesbetween the measured width 231 and height 232 ratios in pixels and the apriori pixel ratios any perceived dimensional distortions can bealgorithmically eliminated. Additionally, the locations of the debit orcredit card account number 233, holder's name 234, and expiration date235 can also be deduced relative to the card image 230 edges and ratios.This greatly simplifies the task of the OCR decoder, since the algorithmwill only concentrate in the areas of the card image 230 that harborvalid data. Of course, as is obvious to anyone skilled in the art, otherinformation (e.g., Card Identification Number—CID) can also be locatedand decoded using this same methodology.

While there are numerous methods for algorithmically determining theedges of a debit or credit card 230, a preferred method is to measurethe color and intensity values of each pixel relative to its neighboringpixels either horizontally or vertically checking for pixels thatexperience a large change or delta from a running average. When a largedelta is detected, the pixel is mapped into a memory array 250 (FIG. 18)that is arranged to two dimensionally represent each pixel in thecamera's field of view. After the entire image is analyzed in thisfashion, the mapped memory area is reviewed by a second process thatattempts to connect lines 252 connecting areas flagged as large deltas251—the line connection process identifying possible card edges. Inaddition to identifying card edges, the line connection process alsotends to filter out stray areas with high deltas 254 as noise since acontinuous line cannot be drawn. As a secondary process, drawn lines canbe tested to intersect at rounded corners, since a debit or credit cardincludes physically specified rounded corners 237 (FIG. 17)—i.e., 3.18mm radius per ISO/IEC 7813. It should also be noted that the mapping andline connection process described above could be enhanced with theadditional of digital filters (e.g., Kalman filter) to smooth out deltasthat may be created by debit or credit card graphics.

Once the card 230 edges are known to the algorithm the differencesbetween the measured lengths of the card 230 widths 231 and 231′ andheights 232 and 232′ can be compared to help determine the skew of card230 relative to the camera. Additionally, measuring the angle ofintersection of the card edges also can be utilized to help determinethe skew of the image.

If multiple images of the card 230 are captured at varying angles, it ispossible for the OCR application to also include a database of anysecurity feature (e.g., hologram 236) present on card 230 with itslocation relative to the card image 230 edges known a priori. In thisembodiment, the security feature database would be organized by debit orcredit account BIN codes. The BIN being extracted from the OCR decodingof the debit or credit card account number 233 of card 230. Thus, if afamiliar BIN was retrieved from the OCR decoded account number, thedetails of the debit or credit card layout can be retrieved from theprocess database. Assuming a security feature is found in the database,the OCR image processing software could also test to determine if thesecurity feature reacts properly to a change in angle of view—e.g.,hologram 236 changing color. Of course, other physical features of thedebit or credit card 230 (e.g., smart card interface connector 238,embossed numbering, etc.) can be stored in the database to also ensurethe card's authenticity. Conversely, if an anticipated security featurereaction was not detected or a debit or credit card 230 BIN was notfound in the database, additional authentication measures may berequired to ensure authenticity.

Returning to the street vendor 220 of FIG. 16. In addition to instantticket sales and lottery redemptions, the disclosed system is alsocapable of selling and printing on-line (e.g., Pick 3, Pick 4, etc.)tickets. When selling on-line tickets the street vendor 220 would eithertype either the specific wager or quick pick request into the touchscreen of the portable tablet computer/communications device 221 orpossible utilize the built-in camera to scan a bet slip. In any case,the on-line sale would be paid for either by cash or (as previouslydiscussed) via debit or possibly credit card. Once the transaction wastendered, the on-line ticket request would be transmitted to the lotterycentral site, the transaction logged on the central site database, witha print ticket data packet returned to portable tabletcomputer/communications device 221, which is then physically printed onthe street vendor's 220 portable printer 222. As previously discussed,due to the invention of T-Macs (i.e., Irwin U.S. Pat. No. 7,788,482 andU.S. Pat. No. 8,037,307) there is no need for special security paper inthe street vendor's 220 portable printer 222. In this embodiment, theT-Mac patents referenced cryptographic functions being performed by theportable tablet computer/communications device 221.

Thus, all of the lottery functionality can be achieved with thedisclosed portable street vendor's system 220. The wireless networkconnectivity linking the street vendor to the lottery central site andpossibly an issuing processor of a debit or credit card.

The previously disclosed debit or credit card interchange piggybackingnetwork is one embodiment that would accommodate the street vendorassuming a wireless cellular or other means is used to link the streetvendor's 220 portable tablet computer/communications device 221 to theissuing processor and the interchange. FIG. 19 illustrates the streetvendor's 220 portable system 220′ communicating to the lottery centralsite 160 via the credit card interchange 120. In this embodiment theinterchange packet transfers would occur as previously disclosed withthe addition of a wireless communications system 260 completing the linkbetween the street vendor's system 220′ and the acquiring processor.However, the encapsulation of the lottery data into a data blob would beperformed digitally with the BIN wrapping accomplished by the portabletablet computer/communications device 221 (FIG. 17) software.

In yet another embodiment, a comparable method can be used to sellpassive game tickets by street vendors. Traditionally these tickets areprinted in advance with unique identifiers—e.g., numbers. Drawings aresubsequently held picking the identifiers that correspond to specificprizes. Unsold tickets for a particular drawing must be returned to thelottery in advance of the drawing requiring up to a two-day delaybetween the cutoff of games sales and the drawing to ensure all unsoldtickets are accounted for. Often there is confusion in the return systemleaving open questions as to which tickets have been sold and which arebeing returned. Additionally, there is also paper waste with the returnof unsold tickets. The mechanism described above for the sale of on-linetickets can be adapted for passive game tickets to eliminate paperwaste, returns, for drawings, and fraud while establishing a clearrecord of sales and 100% inventory control via the central system.

In this embodiment, the passive game tickets 224 (FIG. 19) would beprinted real time with the street vendor's printer with each printedticket including unique identifiers 227 as well as an unique serialnumber 225 assigned by the central site, and optionally a barcode 226.Thus, in this embodiment, there would be no preprinting of unsoldtickets, with winning tickets readily redeemed via serial number lookup.

Alternatively, preprinted passive tickets 224′ (FIG. 20) could still besold through street vendors with the ticket's serial number 225′ and226′ (barcoded embodiment of serial number) scanned and recorded in acentral site database at the time of sale. When the passive game drawingis conducted, only preprinted tickets that were registered as sold onthe central site would qualify for redemption. Therefore, in thisalternative embodiment, the logistical and security problems associatedwith unclear record of sales and inventory control would still beeliminated, but possible problem of paper waste remains. However, if theserial numbers 225′ and 226′ associated with preprinted passive gametickets 224′ were arranged such that any preprinted ticket would qualifyfor any potential drawing, with the registration of the serial number225′ and 226′ tying the ticket to a particular drawing, the paper wasteproblem would also be eliminated. If this embodiment is employed, it maybe helpful for the street vendor to print out a receipt specifying theassociated preprinted passive game ticket's serial number with thedrawing's date and time to eliminate confusion and/or false claims.

Notice that the above network can be readily modified to have theadvantage of the street vendor 220′ using the card issuing processor asalso the acquiring processor 110′—FIG. 22. As shown in FIG. 22, withthis embodiment, there is no need for an interchange, since the issuingand acquiring processors 110′ are the same entity. This elimination ofthe interchange as well as a separate acquiring processor also removesthe associated interchange and acquiring processor fees, thus reducingthe communication related cost of the transaction. This reduction incosting helping to fund the cost of supplying the street vendor 220′with not activated debit cards to hand out (activated) for prizes.

A typical lottery transaction with the preferred, cost reduction,embodiment of FIG. 22 would proceed similar to before. For example, aninstant ticket validation scenario, the consumer 100′ presents anapparent winning instant ticket 155 to the street vendor 220′. In thisexample, the street vendor 220′ would scan the barcode that waspreviously hidden under the SOC of the instant ticket which is formattedto be compatible with the debit or credit interchange format—see 190FIG. 9. The street vendor's 220′ (FIG. 22) portable tabletcomputer/communications device 221 (FIG. 16) would then transmit thescanned barcode data through a Radio Frequency (RF) link 260 (FIG. 22)that would route the data packet to the acquiring processor 110′.However in this embodiment, the acquiring server would extract the BINfrom the transmitted packet and realize the acquiring 110′ and issuingprocessor 110′ are one of the same—i.e., the BIN is identified asbelonging to the issuing/acquiring processor. This BIN recognitionallows the acquiring processor 110′ server to route the data packetdirectly to the issuing processor 110′ server to thereby bypassing theinterchange and the associated fees. The issuing processor 110′ serverwould then detect the lottery BIN and forward the validation data packetto the lottery central site 160 via the direct channel 161. The lotterycentral site would then extract the validation data from the data blob192 (FIG. 9) to determine if the ticket is a winner and that it has notbeen previously cashed. Assuming the ticket is a winner and notpreviously cashed, the lottery central site would issue anacknowledgement payment data packet, returning the acknowledgementpayment data packet back through the channel 161 (FIG. 22) to theissuing and acquiring processor 110′. The issuing and acquiringprocessor 110′ would then relay the acknowledgement payment data packetthrough the wireless interface 260 back to the street vendor 220′ fordisplay and printout.

If the street vendor 220′ and consumer 100′ elect to complete thetransaction with a debit card, the consumer 100′ would either hand hisauthorized debit card (e.g., a debit card from a previous lotterywinning, a debit card issued by the same issuing processor 110′, aGeneral Purpose Reloadable (GPR) card, etc.) to the street vendor 220′or the street vendor 220′ would activate one of the un-activated debitcards he or she carries. In either case, the street vendor would thensend a payment load request for the prize amount to the issuing andacquiring processor 110′ via the wireless communications link 260. Theissuing and acquiring processor 110′ would then transfer the winningfunds from the lottery's bank account to the account associated with thedebit card. Once the transfer was completed and an acknowledgmentreceived, the street vendor 220′ would then hand the loaded debit cardto the consumer 100′.

As illustrated in FIG. 21, this network can be modified in yet anotherembodiment to have street vendor 220′ communicating wirelessly 260directly with the lottery central site 160. As shown, with thisembodiment, there is no need for interchange packet formatting, sincethe communication between the street vendor 220′ and the lottery centralsite 160 is via a direct link. Thus, normal lottery transactions,including instant ticket activation are accomplished directly. However,by adding a direct connection 270 from the lottery central site 160 tothe acquiring processor, all lottery transactions from all merchants canbe conducted through a single interface 270 to the acquiring processor.There are several benefits to this embodiment. The first is byaggregating all debit (or possibly credit) card transactions through asingle acquiring processor the volume discounts on transaction feeswould most likely exceed what most merchants could achieve on their own.Another benefit is the high volume of funds flowing through the sameacquiring processor may also qualify the lottery and its merchants forspecial discounts. Yet another benefit is, as shown in FIG. 23,aggregating all lottery transactions through a common acquiringprocessor 110′ allows the same entity to function as issuing processor110′ for lottery BIN debit cards. As previously described, having acommon acquiring and issuing processor 110′ allows the debit cardtransaction to be conducted free of the interchange thereby avoidinginterchange related transaction costs. Aside from reducing cost to thelottery and its affiliates, this type of interface could also enablemicro or nano payments for other lottery transactions—e.g., Internetlottery website with a penny play on a virtual slot machine. (It shouldbe noted that the terms “micro”- and “nano”-payments refer to smallpayments—typically less than $2 for micropayments and less than $1 fornano payments—for small goods and services offered over the Internet.)In other words, the existing debit/credit card interchange typicallygarners a processing fee close to the cost of a nano payment. However,with the aggregate acquiring processor embodiment of FIG. 23, it canbecome possible for the combined acquiring and issuing processor 110′ tocharge no fees for select transactions since its actual cost pertransaction is virtually nil. The combined acquiring and issuingprocessor 110′ making its profit from other transactions made withlottery funds.

Of course, the lottery central site connected to common acquiringprocessor embodiment could also be used to access the debit or creditinterchange and thereby issuing processors other than the acquiringprocessor (not shown in FIG. 23). Also, as is obvious to anyone skilledin the art, this same direct link to the lottery central site with adirect channel to an acquiring processor can also be applied to a fixedlocation lottery merchant as well.

Finally, consumer off-the-shelf hardware (e.g., smart telephone, tablet,etc.) can be adapted through custom applications to create a mediumallowing the consumer to place specific wagers over a lottery network.In this embodiment, a lottery specific application is downloaded ontothe consumer's off-the-shelf hardware to provide both a user interfaceas well as communications link to the lottery network. For example, FIG.24 depicts a smart telephone 275 running a lottery specific application276 allowing the consumer to place a Lotto type bet by either choosingspecific numbers 277 or by requesting a quick pick 278 via the touchscreen virtual button interface. Ideally, the lottery specificapplication 276 would also allow different amounts to be wagered 279 aswell as multiple drawings 280.

In any case, once the wager(s) have been entered into the smarttelephone 275 application 276, the smart telephone 275 must register thewager with the lottery network. There are multiplicities of methods toaccomplish this registration process.

In one embodiment, a local Radio Frequency (RF) link (e.g., 802.11,Bluetooth, Near Field Communications—NFC, etc.) between the smarttelephone and the lottery retailer's device (either a traditional storeor a street vendor) can transfer the wager information. If a streetvendor 220 (FIG. 16) is equipped with a portable tabletcomputer/communications device 221, the local RF link could'then berelayed over the debit or credit interchange 120 (FIG. 19). In thisembodiment, the smart telephone 275 (FIG. 24) application 276 or therelay process in the street vendor's portable tabletcomputer/communications device 221 (FIG. 16) would automatically formatthe wager request in a configuration that is compatible with the proxydata packet 205 (FIG. 13) normally passed over the debit or creditinterchange. In other words, with the lottery BIN 206 concatenated to adata blob 207 containing the on-line wager request. Of course, theon-line wager request as with any RF link is susceptible to electroniceavesdropping and spoofing, thus any local RF system should preferablyemploy electronic countermeasures to protect against unscrupulousattacks. For example, the Subscriber Identity Module (SIM) present inmost mobile devices is used to participate in a challenge-responsedialogue authenticating the transaction to the mobile device.Alternatively, the mobile device and retailer terminal could negotiatean encryption key via a known key exchange protocol (e.g.,Diffie-Hellman—Hellman et. al., U.S. Pat. No. 4,200,770). Finally, thestreet vendor 220′ (FIG. 25) could also be communicating 260 directlywith the lottery's central site 160. In this embodiment the formattingof the wager request would not necessarily be configured to becompatible with the debit or credit interchange format.

However, the above embodiments have the disadvantage of not beingcompatible with existing brick and mortar retailer POS equipment,consequently requiring custom hardware and/or software with theassociated logistical challenges and costs. In a preferred embodiment,the consumer's smart telephone 275 (FIG. 25) application 276′ wouldaccomplish the lottery network wager registration process byautomatically changing its display to a barcode 281 that is formatted tobe compatible with the proxy data packet 205 (FIG. 13) normally passedover the debit or credit interchange. In this embodiment, two barcodedisplays 281 (FIG. 25) may be necessary, with the first barcodeformatted to resemble the UPC that triggers a lottery transaction andthe second being formatted with the lottery BIN 206 (FIG. 13)concatenated to a data blob (207) containing the on-line wager request.This embodiment having the added advantage of the data blob (207)optionally containing the data associated with a specific wager ratherthan a generic quick pick request.

Once the smart telephone 275 (FIG. 25) barcode data 281 is scanned bythe retailer's POS equipment 105 (FIG. 11), the request would be routedas previously discussed through the acquiring processor 110 and theinterchange 120, to the issuing processor 125 and ultimately to thelottery's central site 160. As before, the on-line wager ticket printcommand would flow back through the same path printing the on-lineticket on the retailer's POS 105 printer. The only difference being thatthe barcode(s) 281 (FIG. 25) used to transfer the wager request over theinterchange were scanned from the consumer's smart telephone 275 ratherthan a preprinted quick pick card 200 (FIG. 12).

Of course, as is obvious to anyone skilled in the art, other consumerdevices (e.g., portable tablet computers, laptop computers, etc.) may beemployed in the same embodiment and may be preferable in some cases.

What is claimed is:
 1. A method for collecting and transmittinginformation desired for a commercial transaction from a debit or creditcard, the method comprising use of a processor configured with opticalcharacter recognition (OCR) capability to perform steps of: collectingat least one optical image of the debit or credit card; algorithmicallydefining the edges of the debit or credit card from the collected image;applying predefined offsets to the algorithmically defined edges of thedebit or credit card to algorithmically locate an area in the collectedimage having the desired transactional data; encoding the transactionaldata within the located area; and transmitting the encoded data forfurther processing of the commercial transaction.
 2. The method of claim1, wherein the area in the collected image contains an account numberassociated with the debit or credit card.
 3. The method of claim 1,wherein the edges of the debit or credit card are algorithmicallydefined by measuring one or both of color and intensity values of pixelsin the optical image, wherein pixels having a defined differential coloror intensity value relative to neighboring pixels are flagged and mappedin a memory array.
 4. The method of claim 3, wherein individual pixelsare compared against a running average of neighboring horizontal orvertical pixels for flagging the pixels having a defined differentialcolor or intensity value relative to neighboring pixels.
 5. The methodof claim 3, further comprising filtering out flagged pixels that are notconnectable by a continuous line to neighboring pixels.
 6. The method ofclaim 3, wherein the mapped memory array is a two dimensionalrepresentation of each pixel in a scanner's field of view used tocollect the optical image, and further comprising connecting linesbetween the flagged pixels, wherein the lines denote edges of the debitor credit card.
 7. The method of claim 6, further comprising detectingrounded corners at intersections of the connected lines as an aid indefining edges of the debit or credit card.
 8. The method of claim 3,further comprising processing the collected optical image with a digitalfilter to smooth out pixels having the defined color or intensity valueattributable to graphics on the credit or debit card.
 9. The method ofclaim 1, further comprising determining a skew orientation of thecollected optical image relative to a scanner or camera used of collectthe optical image.
 10. The method of claim 9, wherein the skeworientation is determined by comparing known width and height dimensionsof the credit or debit card to measured width and height dimensionsobtained from the algorithmically defined edges.
 11. The method of claim9, wherein the skew orientation is determined by measuring an angle ofintersection of the algorithmically defined edges.
 12. The method ofclaim 1, further comprising retrieving attributes of known securityfeatures embedded in the credit or debit card from a database, andtesting the collected optical image with the OCR software to determineif the collected image contains the security feature attributes.
 13. Themethod of claim 12, wherein the security feature database is organizedby credit or debit card back identification number (BIN), the area inthe collected image having the transactional data contains an accountnumber associated with the debit or credit card, wherein the BIN isextracted from the account number and used to access the securityfeature database.